U.S. Pat. No. 4,207,609 discloses a system used in common in circumstances, where files are shared.
In a magnetic disk subsystem, in some cases, a system, where a disk device is shared by a plurality of CPUs, i.e. a multiple control system is used. For example, in the case where a magnetic disk device 10 is utilized by 3 systems, as indicated in FIG. 1, each of CPUs 1 to 3 has 2 access paths to the disk device 10. An input command coming from each of the CPUs accesses the destination disk device through a channel 4, a channel switch 5, a magnetic disk control device (hereinbelow abbreviated to DKC) 6, 7 and a disk connection device (hereinbelow abbreviated to DSC) 8. A memory 9 in the DSC 8 stores data of channel command during utilization of the device and is used in common by a plurality of paths.
In this case it is usual that an in/output device shared by a plurality of hosts reports, when it is being operated under a command from a host, for a command from another host that it is busy and after the termination of the operation it sends a busy to free report to the host to whom it has reported to be busy. However, depending on circumstances of the utilization of the system, a following problem may occur. That is, in circumstances where a host gives commands successively to a device, when another host gives a command to the same device, it receives a report that the device is busy, if the device is being operated, and gives again the same command, if it receives a busy to free report, after the termination of the operation. At this moment, if the same device is being again operated, it receives again a report that the device is busy. There can be produced cases where these circumstances are repeated and no command from the other host cannot be processed.
FIG. 2 is a sequence chart showing these circumstances, illustrating a case where 2 CPUs access an in/output device. At first, CPU 1 catches the device and carries out operations such as seek of read/write head, search, read/write, etc. (period indicated by hatching). During this period, if CPU 2 gives an in/output command to the device, since it is used by CPU 1, the device reports DEVICE BUSY to CPU 2. After that, at a point of time, where the operation for CPU 1 is terminated, the device sends a busy to free report to CPU 2 in order to demand to send again the same command. Receiving the report, CPU 2 gives again the same command. However, in the case where CPU 1 accesses the same device several times repeatedly, a new command from CPU 2 encounters again DEVICE BUSY. Therefore, even if a B.T.F. report is sent to CPU 2, since the device is used again by CPU 1, after a time t.sub.1 has passed away, at a point of time where a new command is given again by CPU 2, CPU 2 cannot use the in/output device.
Next, in a method for resolving this problem, "BUSY RETRY" can be applied, which is a function in a channel interface indicated in FIG. 3. During a period of time, where CPU 1 uses the device, everytime when CPU 2 gives a command thereto, a control device 5 or 6 sends a "BUSY RETRY" to CPU 2. Receiving it, the host CPU 2 judges that the command has been received by the device and enters into a state, where it waits a command termination report from the control device. After the termination of an operation 11 of the device for CPU 1, the control device connects again the device with the channel, which has asked the BUSY RETRY, and reports B.T.F. to CPU 2 in order to ask it to give again the command. In this case, since the operations from the reconnection with the channel to the reissue of the command can be carried out at the channel level, the time necessary therefor (t.sub.0 in FIG. 3) is considerably shortened with respect to that (t.sub.1 in FIG. 2) from the BUSY TO FREE report to the reissue of the in/output command according to the prior art techniques. The channel gives again the command asked to retry and the control device processes the command at first and others thereafter. Consequently, even in the case where CPU 1 uses the in/output device repeatedly, since the reissued command from CPU 2 can access the control device earlier than the next command from CPU 1, CPU 2 can use the device, after CPU 1 has terminated to use it at first. Then, after the operation at the command from CPU 2 has been terminated, a BUSY TO FREE report indicating that the device is set free is sent to CPU 1. Since a BUSY RETRY is given previously to CPU 1, the reissue of a second command, which has been already stored in the channel, is carried out immediately and then CPU 1 can use the device subsequently as indicated by 14 in FIG. 3. In this way 2 hosts can use the device alternatively. Since the reissue of the command at the channel level requires no intervention of the hosts, it can be carried out generally within a period of time from an in/output command termination report to the issue of the following command, but in the case where timing of the report by the control device is retarded or due to the fact that the performance of the CPUs is ameliorated, it can happen that the device cannot be used alternatively and thus further improvement thereof is needed.
FIG. 4 is an operation sequence chart in this case. In the case where CPU 2 accesses the device and after that CPU 3 also accesses it during a period of time, where CPU 1 uses the device, since both of them ask the reconnection, BUSY RETRYs are sent to both. At the point of time, where the use of the device by CPU 1 is terminated, a termination report is sent to of CPUs 2 and 3. Supposing that the performance of CPU 3 is slightly worse than that of CPU 2, the reissue, indicated by 15 in FIG. 4, of the command from CPU 3 is later than that from CPU 2. Finally, in the case where CPUs 1 and 2 use the device repeatedly, CPU 1 and CPU 2 use the device alternatively and CPU 3 can never use it.